I'm not sure if this is workable, at least in v1, as this would be a breaking change to IDL consumers. For example, declare_program parses the value as a Rust expression and emits it directly:

So this causes declare program to emit const MY_CONSTANT: &str = value, which would fail to compile with identifer value not found.

I'm not sure if this is workable, at least in v1, as this would be a breaking change to IDL consumers. For example, declare_program parses the value as a Rust expression and emits it directly:

anchor/lang/attribute/program/src/declare_program/mods/constants.rs

Lines 25 to 37 in 4172f22

	let val = syn::parse_str::<syn::Expr>(&c.value)
	.unwrap()
	.to_token_stream();
	let val = match &c.ty {
	IdlType::Bytes => quote! { &#val },
	IdlType::Pubkey => quote!(Pubkey::from_str_const(stringify!(#val))),
	_ => val,
	};
	quote! {
	#docs
	pub const #name: #ty = #val;
	}

So this causes declare program to emit const MY_CONSTANT: &str = value, which would fail to compile with identifer value not found.

i updated the approach so the JSON IDL still keeps string constant values as Rust expressions, preserving compatibility with declare_program and other IDL consumers....

the change is now limited to the generated TypeScript type helper, where string literal constants are normalized for target/types/*.ts only...

What exactly are the new changes doing?

What exactly are the new changes doing?

the new changes keep the actual JSON IDL unchanged for compatibility: string constants are still stored as Rust expressions, e.g. "\"favor\"", so declare_program and other Rust-side IDL consumers continue to work...

the only behavior change is in the generated TypeScript type helper (target/types/*.ts). before rendering that TS type, string constant values that are valid JSON string literals are decoded once, so "\"favor\"" is shown as "favor" in the generated TS helper. Non-literal values like SEED_PREFIX are left unchanged...

Can you add a test for the real behavioral change, and update the PR title/description to reflect it?

Actually sorry, I'm going to close this based on the reasoning in the linked issue. I don't think this break is worth it.